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Foreword 



rd , 



This Technical Report has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document contains technical performance objectives that should be met for the fixed infrastructure of GSM 
PLMNs. Concerning transmission delay for the PLMN in clause 4, the requirements should also be met by GSM 
Mobile Stations (MS)s. 

These performance design objectives are applicable to all implementations at all points in the growth cycle up to the 
maximum size. These reference loads and performance objectives may be used by manufacturers in designing GSM 
PLMNs and by Administrations or Recognised Private Operating Agencies (RPOA)s in evaluating a specific design or 
for comparing different designs for potential use in the Administration's or RPOA's intended implementation. 

1.1 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] Void. 

[2] 3GPP TS 23.002: "Network architecture". 

[3] 3GPP TS 43.050: "Transmission planning aspects of the speech service in the GSM Public Land 

Mobile Network (PLMN) system". 

[4] 3GPP TS 45 .0 1 0: "Radio subsystem synchronization" . 

[5] ITU-T Recommendation E.600: "Terms and definitions of traffic engineering". 

[6] ITU-T Recommendation G.921: "Digital sections based on the 2048 kbit/s hierarchy". 

[7] ITU-T Recommendation Q.541: "Digital exchange design objectives - General". 

[8] ITU-T Recommendation Q.543: "Digital exchange performance design objectives". 

[9] ITU-T Recommendation Q.55 1 : "Transmission characteristics of digital exchanges". 

[10] ITU-T Recommendation Q.554: "Transmission characteristics at digital interfaces of a digital 

exchange". 

[II] ITU-T Recommendation Q.702: "Specifications of Signalling System No. 7 - Signalling data link". 

[12] ITU-T Recommendation Q.706: "Message transfer part signalling performance". 

[13] ITU-T Recommendation V.llO: "Support of data terminal equipments (DTEs) with V-Series 

interfaces by an integrated services digital network". 

[14] CEPT Recommendation T/S 64-30: "Digital exchange performance design objectives". 

[15] 3GPP TS 21.905: "Vocabulary for 3GPP Specifications" 

[16] 3GPP TS 11.30: "Mobile Services Switching Centre Phase 1" 

[17] 3GPP TS 11.31: "Home Location Register Specification Phase 1" 

[18] 3GPP TS 1 1.32: "Visitor Location Register Specification Phase 1" 
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1 .2 Abbreviations 

Abbreviations used in the present document are listed in 3GPP TS 21.905 [15]. 

2 General 

For terminology and architecture for GSM PLMNs see 3GPP TS 23.002 [2]. 

Interfaces, interface characteristics, connections through an MSC and ancillary functions of the MSC are defined in 
3GPPTS 11.30 [16]. 

The functions supported by HLRs and VLRs are given in 3GPP TS 11.31 [17] and 11.32 [18]. 

Each MSC will be responsible for synchronisation, if required, with the fixed network to which it is connected. The 
requirements of ITU-T Recommendation Q.541 should be observed. 

Timing and synchronisation of the radio subsystem is specified in the 3GPP TS 45.010 [4]. 

3 Performance design objectives 

3.1 General 

Part of the text is taken from ITU-T Recommendation Q.543 and part from CEPT Recommendation T/S 64-30. 

3.2 MSCs 

3.2.1 Reference loads 

The reference loads are traffic load conditions under which the performance design objectives stated below are to be 
met. The following reference loads are defined. 

a) Reference load for incoming inter-exchange circuits; 

b) Reference load for circuit switched MS calls. 

Reference load A is intended to represent the normal upper mean level of activity which Administrations or RPOA's 
would wish to provide for MSs, BS-MSC circuits and inter-exchange circuits. Reference load B is intended to represent 
an increased level beyond normal planned activity levels. 

3.2.1 .1 Reference load on incoming interexchange circuits 

a) Reference load A 

0,7 Erlang average occupancy on all incoming circuits with 35 call attempts/hour/incoming circuit. 
This figure assumes 45 % ineffective call attempts. 

b) Reference load B 

0,85 Erlang average occupancy on all incoming circuits with 42 call attempts/hour/incoming circuit. 

3.2.1 .2 Reference load for MS calls 

MS calls comprise MS originating and MS terminating traffic. Terminating call attempts from PSTN/ISDN to the MS 
are measured at the PSTN/ISDN interface of the PLMN. Terminating call attempts as part of the intra-PLMN MS-to- 
MS call attempts are measured at the GMSC functionality in the VMSC. 
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a) Reference load A 



Table 1 : Traffic model for circuit switched MS calls 



MS type 


Average traffic 


Average 


Overall mean 




intensity 


BHCA/sbscr 


holding time 




(ErI/sbscr) 




(s) 


W 


0.010 


0.60 


60 


X 


0.018 


1.00 


65 


Y 


0.030 


1.50 


72 


Z 


0.050 


2.00 


90 



The data sets for MS types W through Y are chosen to cover field observations in various continents, countries and 
regions. With an increase of traffic per subscriber, the overall mean holding time tends to increase. The set Z is chosen 
as an extreme value, expressing the expectation that such a large value should only be observed in association with a 
substantially increased overall mean holding time. 

b) Reference load B 

Reference load B is defined as a traffic increase over reference load A of: 

+ 20% in Erlangs and. 

+ 20% in BHCA. 

3.2.1 .3 Impact of supplementary services 

If the reference model MSC assumes that significant use is made of supplementary services, the performance of the 
MSC can be strongly affected, especially in designs where processor capacity can become a limiting item. The 
performance delays recommended can be significantly lengthened at a given call load under such circumstances. The 
Administration or Operating Agency defining the reference model should estimate the fractions of calls which use 
various supplementary services so that an average processor impact relative to a basic telephone call can be calculated. 

3.2.2 Inadequately handled call attempts 



3.2.2.1 



Definition 



Inadequately handled call attempts are attempts which are blocked (as defined in ITU-T E.600 series of 
Recommendations) or are excessively delayed within the exchange. "Excessive delays" are those that are greater than 
three times the "0,95 probability of not exceeding" values recommended in the tables. 

For originating and transit calls, this inadequately handled call attempt parameter applies only when there is at least one 
appropriate outlet available. 

3.2.2.2 Probability of inadequately handled call attempts occurring 

The values in table 2 are recommended. 

Table 2 



Type of connection 


Reference Load A 


Reference load B 


Internal 


<10-2 


<4 X 1 0-2 


Originating 


<5 X 1 0-3 


<3x10-2 


Terminating 


<2 X 1 0-3 


<2 X 1 0-2 


Transit 


<10-3 


<10-2 
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3.2.3 Delay probability 



The following notes apply to the delay parameters included in this section: 

1) The term "mean value" is understood as the expected value in the probabilistic sense. 

2) The terms "received from" and "passed to" the signalling system are meant to be that instant at which the 
information is exchanged between the signalling data link (layer 1) and the signalling link functions (layer 2) in 
ITU-T Signalling System No. 7. For Dm channel signalling it is designated as that instant when the information 
is exchanged between the data link layer (layer 2) and the network layer (layer 3) by means of primitives. 
Consequently, the specified time intervals exclude the layer 1 and layer 2 times. However, they do include 
queuing delay in the absence of disturbances, but not additional queuing caused by retransmission of signalling 
messages. 

3) It is indicated where processing phases handled in entities other than the MSC/VLR are included in the defined 
call phases; estimates likely to give the correct order of magnitude for the overall delay are given. This makes it 
easy to re-use monitoring equipment available for exchanges for the MSC/VLR. It also gives an indication of the 
call handling delays to be expected in a mobile network. 



3.2.3.1 



User signalling acknowledgement delay 



User signalling acknowledgement delay is the interval from the instant a user signalling message has been received 
from Dm channel until a message acknowledging the receipt of that message is passed back from the MSC to Dm 
channel. Examples of such messages are SETUP ACKNOWLEDGEMENT to SETUP, CONNECT 
ACKNOWLEDGEMENT to CONNECT, and RELEASE ACKNOWLEDGEMENT to RELEASE. 



The values in table 3 are recommended. 



Table 3 





Reference load A 


Reference load B 


Mean value 


<400 ms 


<800 ms 


0.95 probability of not 
exceeding 


600 ms 


1000 ms 



3.2.3.2 



Signalling transfer delay 



The MSC signalling transfer delay is the time taken for the MSC to transfer a message from one signalling system to 
another with minimal or no other exchange actions required. The interval is measured from the instant that a message is 
received from a signalling system until the moment the corresponding message is passed to another signalling system. 
Examples of messages are ALERT to ADDRESS COMPLETE, ADDRESS COMPLETE to ADDRESS COMPLETE, 
CONNECT to ANSWER, RELEASE to DISCONNECT etc. The values in table 4 are recommended for originating and 
terminating connections. 

Table 4 





Reference load A 


Reference load B 


Mean value 


<200 ms 


<350 ms 


0.95 probability of not 
exceeding 


400 ms 


700 ms 



3.2.3.3 



Through connection delay 



a) For originating outgoing traffic through connection delay is defined as the interval from the instant that the 
signalling information required for setting up a connection through the MSC is received from the incoming 
signalling system to the instant that the transmission path is available for carrying traffic between the incoming 
and out going terminations on the MSC. 



£75/ 



3GPP TS 43.005 version 9.0.0 Release 9 



10 



ETSI TS 143 005 V9.0.0 (2010-02) 



Switching through for mobile originating calls outgoing from the MSC occurs in two stages. The first stage is for 
the backward path with the delay between SETUP from the MS and JOIN_PATH for the B side. The second 
stage is for the forward path with the delay between ANSWER and JOIN_PATH for the A side. 

The first stage encompasses the call set-up delay, hence the recommended values for the Call Set-up Delay in 
Section 3.2.3.8 apply. 

The second stage encompasses the signalling transfer delay between ANSWER and CONNECT, hence the 
Signalling Transfer Delay in Section 3.2.3.2 applies. 

b) for internal and terminating traffic the through connection delay is defined as the interval from the instant that 
the CONNECT message is received from the Dm channel until the through connection is established and 
available for carrying traffic and the ANSWER and CONNECT ACKNOWLEDGEMENT messages have been 
passed to the appropriate signalling systems. 



The values in table 5 are recommended. 



Table 5 





Reference load A 


Reference load B 


Mean value 


<250 ms 


<400 ms 


0.95 probability of not 
exceeding 


300 ms 


600 ms 



3.2.3.4 Incoming call indication sending delay - (for terminating and internal traffic 

connections) 

The incoming call indication sending delay is defined as the interval from the instant at which the necessary signalling 
information is received from the signalling system to the instant at which the SETUP message is passed to the signalling 
system of the called subscriber. 

This phase contains three parts that are handled in the BSS or in the MS, namely 

- paging; 

RACH and SDCCH signalling for access to the network; 

- authentication. 

The recommended delays in tables 7 and 8 include estimates of these delays together with the MSC processing. 
In the case of overlap sending in the incoming signalling system, the values in table 6 are recommended. 

Table 6 





Reference load A 


Reference load B 


Mean value 


<4000 ms 


<4700 ms 


0.95 probability of not 
exceeding 


4700 ms 


5200 ms 



In the case of en-bloc sending in the incoming signalling system, the values in table 7 are recommended. 

Table 7 





Reference load A 


Reference load B 


Mean value 


<4600 ms 


<4900 ms 


0.95 probability of not 
exceeding 


4900 ms 


5300 ms 
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3.2.3.5 



Connection release delay 



Connection release delay is defined as the interval from the instant when DISCONNECT or RELEASE message is 
received from a signalling system until the instant when the connection is no longer available for use on the call (and is 
available for use on another call) and a corresponding RELEASE or DISCONNECT message is passed to the other 
signalling system involved in the connection. The values in table 8 are recommended. 

Table 8 





Reference load A 


Reference load B 


Mean value 


<250 ms 


<400 ms 


0.95 probability of not 
exceeding 


300 ms 


700 ms 



3.2.3.6 



Call clearing delay 



Disconnect and call clearing will usually be performed at the same time. However, on certain calls it may be necessary 
for an exchange to retain call references after disconnect has occurred, until a clearing message is received. The 
exchange may then discard the call reference information. The corresponding RELEASE message must be passed on to 
other involved signalling systems in the interval allowed for signalling transfer delay. 



3.2.3.7 



Timing for start of charging (circuit switched calls) 



When required, timing for charging at the MSC where this function is performed, shall begin after receipt of an 
ANSWER indication from a connecting exchange or the called user. The start of timing for charging should occur 
within the intervals recommended in table 9: 

Table 9 





Reference load A 


Reference load B 


Mean value 


<100 ms 


<175 ms 


0.95 probability of not 
exceeding 


200 ms 


350 ms 



3.2.3.8 



Call set-up delay 



The call set-up delay for mobile originating calls outgoing from the MSC is measured from SETUP received until lAM 
sent. This phase also contains the assignment of the air interface traffic channel performed in the BSS. It is assumed that 
all call handling data are available in the VLR at set-up time. 



The values in table 10 are recommended. 



Table 10 





Reference load A 


Reference load B 


Mean value 


<1 900 ms 


<2200 ms 


0.95 probability of not 
exceeding 


2100 ms 


2400 ms 



3.2.3.9 Handover delay 

Two cases are to be defined 

a) between BSs of the same MSC; 

b) between BSs of different MSCs. 
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objectives are for further study and should include: 
i) interruption of communication path; 
ii) probability of success where initiation was successful. 

3.2.3.10 Off-air-call-set-up (OACSU) delay 

OACSU delay is the extra delay in switching the speech path from A- to B-subscriber because of seizing the radio path 
after the B-subscriber has hooked-off. It is defined as the interval that the answer indication is received from the B- 
subscriber until the instant when the radio path has been successfully seized. 

The values in table 1 1 are recommended. 

Table 11 





Reference load A 


Mean value 


<1000 ms 


0.95 probability of not 
exceeding 


5000 ms 



3.2.3.1 1 Discontinuous reception mode delay 

For further study. 

3.2.4 Call processing performance objectives 

3.2.4.1 Premature release 

The probability that an MSC malfunction will result in the premature release of an established connection in any one 
minute interval should be: 

p < 2 X 10-' 

3.2.4.2 Release failure 

The probability that an MSC malfunction will prevent the required release of a connection should be: 

p < 2 X 10-' 

3.2.4.3 Incorrect charging or accounting 

The probability of a call attempt receiving incorrect charging treatment due to an MSC malfunction should be: 

p < 10-' 

3.2.4.4 Misrouting 

The probability of a call being misrouted following receipt by the MSC of a valid address should be: 

p<10-' 

3.2.4.5 No tone 

The probability of a call attempt encountering no tone following receipt of a valid address by the MSC should be: 

p < 10-' 
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3.2.4.6 Other failures 

The probability of the MSC causing a call failure for any other reason not identified specifically above should be: 

p < 10-' 

3.2.4.7 Transmission performance 

The probability of a connection being established with an unacceptable transmission quality across the exchange should 
be: 

p (unacceptable transmission) < 10' 

The transmission quality across the exchange is said to be unacceptable when the bit error ratio is above alarm 
condition. 

NOTE: The alarm condition has yet to defined. 

3.2.4.8 Slip rate 

The slip rate under normal conditions is covered in ITU-T Recommendation Q.541. 

3.2.5 MSC performance during overload conditions 

The requirements stated in ITU-T Recommendation Q.543 should be met. 

3.3 Performance design objectives for HLRs 

3.3.1 Reference loads 

a) Reference load for call handling: 0,4 transactions per subscriber per hour. 

b) Reference load for mobility management: 1,8 transactions per subscriber per hour. 

3.3.2 Objectives 

The following objectives for delay times are independent of the size of the HLR and are 95% values. 

a) The probability of loosing messages should be according to the ITU-T Recommendation Q.706: 

p (loosing messages) < 10"^ 

b) The delay for retrieval of information from the HLR (retrieval on a per call basis, retrieval of the authentication 
etc.) should be less than 1000 ms 

2c) The delay for location registration in the HLR should be less than 2000 ms. 

3.4 Performance design objectives for VLRs 

3.4.1 Reference loads 

a) Reference load for call handling: 1,5 transactions per subscriber per hour 

b) Reference load for mobility management: 8,5 transactions per subscriber per hour. 

3.4.2 Objectives 

The same objectives as for HLRs apply (see section 3.3.2). 
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4 Transmission characteristics 

4.1 General 

4.1.1 BS-MSCpath 

The performance objectives of BS-MSC path are dependent on length of the link and therefore they will be decided on 
national basis. However, they should be fixed taken into account ITU-T Recommendation G.921. 

4.1.2 MSC 

The MSC should meet the transmission objectives of digital exchanges as specified in ITU-T Recommendation Q.551 
and Q.554. 

4.2 System delay distribution 

3GPP TS 03.50 specifies an overall transmission delay objective throughout the PLMN for speech channels for reasons 
of subjective speech quality. Since this transmission delay objective includes several physical network elements, this 
section specifies transmission delay values allocated to each of them. Due to in-band protocols implemented in the 
GSM PLMN with timers running across several network entities, also the transmission delay for data channels must be 
limited and allocated to the physical network elements. 

4.2.1 Speech channel delay 

The main problem arising from an excessive delay occurs in a speech channel because of subjective effects of echo and 
simultaneous speech in both directions. To minimise these effects a both way speech delay of 180 ms between the 
Mouth Reference Point (MRP)/ Ear Reference Point (ERP) in the MS and the Point Of Interconnection (POI) with the 
PSTN/ISDN has been specified in 3GPP TS 03.50 as an objective for the GSM PLMN operator when constructing his 
network. 

This delay for the full rate speech channel has been loosely allocated to the various system entities as follows and 
illustrated in fig 4/1 and fig 4/2. The detailed delay figures internal to a system entity are only indicative. The total delay 
allowance allocated to any of the system entities should, however, not be exceeded. The propagation delay through the 
PLMN is not included. It should be noted that even if the sum of allocated delay values may exceed 180 ms in some 
cases, the long-term objective is still to keep the overall PLMN transmission round-trip delay below 180 ms. 

The allocated delay allowances are indicated as either system dependent or implementation dependent. By system 
dependent it is meant that the delay values are worst-case delay values given by system-given units of time, and cannot 
be changed. By implementation dependent it is meant that the values depend on the technology used, and that the values 
allocated have been fixed as upper bounds by realistic judgement. 

NOTE: The various figures allocated to the various network entities given in these delay budgets are for guidance 
to network operators for network planning. It is up to the operator to provide other figures, if required. 
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Figure 4/1 a: Downlink delay distribution for TCH/FS (16Kbit/s Abis) 
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Figure 4/1 b: Uplink delay distribution for TCH/FS (16 Kbit/s Abis) 
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Figure 4/2a: Downlink delay distribution for TCH/FS (64 Kbit/s Abis) 
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Figure 4/2b: Uplink delay distribution for TCH/FS (64 Kbit/s Abis) 

BSS internal delay values (indicative): 

Tsample: The duration of the segment of PCM speech operated on by the full-rate speech transcoder (system 

dependent). 

Trftx: The time required for transmission of a TCH radio interface frame over the air interface due to the 

interleaving and de-interleaving (given in table 4/2) (system dependent). 

Tabisu: The time required to transmit the first 56 speech frame data bits (bits C12-C15, D1-D56 and 4 

synchronization bits - 64 bits) over the 16 kbit/s A-bis-interface in the uplink direction (system 
dependent). 

Tabisd: The time required to transmit the 260 speech frame data bits (bits D1-D260, C16 and 17 

synchronization bits - 278 bits) over the 16 kbit/s A-bis-interface in the downlink direction (system 
dependent). 

Tbuff: Due to the time alignment procedure for inband control of the remote transcoder in case of a 16 kbit/s 

A-bis-interface in the downlink direction, it is required to have a buffer in the BTS of 1 ms H- one 250 
us regulation step (system dependent). 

Tbsc: Switching delay in the BSC (implementation dependent). 

Ttransc: The speech encoder processing time, from input of the last PCM sample to output of the final encoded 

bit (implementation dependent). 

Tsps: Delay of the speech encoder after reception of the last PCM sample until availability of the first 

encoded bit (implementation dependent). 

Tencode: The time required for the channel encoder to perform channel encoding (implementation dependent). 

Trxproc: The time required after reception over the radio interface to perform equalization, channel decoding 

and SID-frame detection (implementation dependent). 

Tproc: The time required after reception of the first RPE-sample to process the speech encoded data for the 

full-rate speech decoder and to produce the first PCM output sample (implementation dependent). 

BSS external delay values (indicative): 

Techo: Delay due to the echo canceller. 

Tmsc: Switching delay in the MSC. 

4.2.2 Data channel delay 

The service requirements on excessive transmission delays for data channels are not as stringent as for speech channels. 
However, two overall requirements apply: 
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1 . Proper operation of the RLP protocol with the timers Tl and T2 residing in the MSC/IWF and in the MS/TA 
must be ensured, and thus the round-trip delay between those network entities must be low enough to avoid time- 
outs of the RLP retransmission timer Tl (Round-trip delay < Tl - T2). This applies to non-transparent data only. 

2. Proper operation of any end-to-end acknowledged protocols must be ensured in a similar manner. This applies to 
all data channels. 

The transmission delay requirements for data channels have been allocated to the various system entities as follows and 
as illustrated in figures 4/3 and 4/4, for transparent and non-transparent data separately, and the requirements in the 
budgets should apply to all full-rate or half-rate channels, whether synchronous or asynchronous. The contributions to 
the round-trip transmission delay seen by the RLP are also indicated. It should be noted that these concern the 
transmission delay part only, and that the timer T2 must be added in order to find the limits for Tl. The detailed delay 
figures internal to a system entity are only indicative. The total delay allowance allocated to any of the system entities 
should, however, not be exceeded. The propagation delay through the PLMN is not included. 

The allocated delay allowances are indicated as either system dependent or implementation dependent. By system 
dependent it is meant that the delay values are worst-case delay values given by system-given units of time, and cannot 
be changed. By implementation dependent it is meant that the values depend on the technology used, and that the values 
allocated have been fixed as upper bounds by realistic judgement. 

It should be noted that the actual delay distribution for a specific data channel in most cases will have a lower total 
transmission delay than indicated in the budgets, which show the worst-cases. 

It should also be noted that the budgets apply to perfect conditions, i.e. no errors over the radio path (implying no re- 
transmissions) and no flow control. It should be noted, however, that in a real life situation any errors on the radio path 
may increase the transmission delay and/or decrease the RLP throughput, and that the flow control buffer limits for 
XON/XOFF will under continuous flow control have a direct impact on the transmission delay, giving an additional 
delay contribution directly given by these buffer limits. 

The following delay values are specific to data traffic channels: 

Transparent data only: 

Tchar: The time needed in the IWF and TA to receive a character at the user bit-rate in the transmit direction 

for bit-to-character conversion (given in table 4/3) (system dependent). 

TraO: The time required for buffering in the IWF and TA in the transmit direction for asynchronous-to- 

synchronous conversion and overspeed/underspeed detection and correction. This delay corresponds 
to Tchar above (given in table 4/3) (system dependent). 

Tnic: The time needed in the IWF in each direction for buffering for Network Independent Clocking. This 

time corresponds to one V.llO frame (system dependent). 

Non-transparent data only: 

T12runit: The necessary time in the IWF and TA in the transmit direction to convert the incoming user data bit 

stream into interpretable data units, e.g. characters (character oriented without framing) or data frames 
(e.g. bit oriented data like HDLC) (system dependent). 

T12rbuft: Worst-case delay in the IWF and TA in the transmit direction required for buffering in the L2R in 

order to assemble one PDU (system dependent). 

Tprotpr: Processing time used in the IWF and TA by the L2R and the RLP in the transmit or receive direction 

(implementation dependent). 

Trlpbuft: Worst-case buffering delay in the IWF and TA required by the RLP in the transmit direction in order 

to synchronize one PDU towards the radio interface transmission (system dependent). 

Trlpbufr: Worst-case delay in the IWF in the receive direction required for buffering in the RLP in order to 

assemble one PDU, before checksum calculation can be carried out (system dependent). 

T12rbufr: Worst-case buffering delay in the IWF and TA required by the L2R in the receive direction in order to 

synchronize one PDU with the L2R user (system dependent). 

Transparent and non-transparent data: 
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Tiwfpr: Processing time in the IWF in the downlink or in the uplink direction (implementation dependent). 

Tabisf: Worst-case delay over the A-bis-interface due to non-synchronized A-bis -interface transmission. This 

delay corresponds to one TRAU frame (system dependent). 

Tdframe: Additional delay to Tabisf in the downlink direction in order to receive a full radio interface data TCH 

frame over the A-bis-interface, so that channel encoding can start. The data TCH frame length is 
given in table 4/1 and Tdframe is summarized in table 4/4 (system dependent). 

Talignd: The time needed to wait in the downlink in order to align the received data over the A-bis-interface to 

the radio interface TDMA frame structure. This time corresponds to one TDMA-frame for full-rate 
channels and two for half-rate channels (system dependent). 

Tframe: Delay in the uplink direction in the MS in order to receive a full radio interface data TCH frame over 

the user interface, so that channel encoding can start. The data TCH frame length is given in table 4/1 
(system dependent). 

Tdbuff: Additional buffering needed in the TA in the uplink direction with respect to Tframe allowing a total 

buffering of four V. 1 10 frames. The V.llO frame length is given in table 4/1, and Tdbuff is 
summarized in table 4/4 (system dependent). 

Talignu: The time needed to wait in order to align the received uplink data over the user interface to the radio 

interface TDMA frame structure. This time corresponds to one TDMA-frame for full-rate channels 
and two for half-rate channels (system dependent). 

Ttaprocd: Processing time required in the TA in the downlink direction for terminal adaptation (implementation 

dependent). 

Ttaprocu: Processing time required in the TA in the uplink direction for terminal adaptation (implementation 

dependent). 

Other delay values indicated in the budgets for data traffic channels are defined as for speech channels. Margins are 
allocated to each system entity for the total implementation dependent part of the delay contributions, considering the 
amount of processes in each entity and the amount of data processed. Those operations not included explicitly in the 
budget are considered only to add minimal delays and are thus considered to be covered by the margins. 

The data channel delay budgets for a 64 kbit/s and a 16 kbit/s A-bis-interface are essentially the same, the only 
difference being a reduction in rate adaptation functions in the 64 kbit/s case and a possible non-synchronized 
transmission over the 16 kbit/s A-bis-interface (Tabisf). Thus only the 16 kbit/s A-bis-interface is illustrated, and for 
this option only the worst-cases. The budgets in figures 4/3 and 4/4 apply, hence, also to the case of a 64 kbit/s A-bis- 
interface. For the case of the integrated BSS the delay budget for the BSS shall contain the sum of the allowances for 
the BSC and the BTS. 

Table 4/1 : Radio interface and V.1 10 frame lengths for traffic channels 



Traffic channel: 


Frame length (ms): 


Radio int. (z): 


V.110(r): 


TCH/FS 

TCH/HS 

TCH/F9.6 

TCH/F4.8 

TCH/H4.8 

TCH/F2.4 

TCH/H2.4 


20 
[tbd] 
20 
20 
40 

40 


5 
10 
10 
10 
10 
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Table 4/2: Interleaving/de-interleaving delay for traffic channels 



Traffic channel: 


Interleaving/deinterleaving 
(TDIVIA-frames/timeslots): 


delay (y) (ms) 


TCH/FS 


7+1/1 


37,5 


TCH/HS 


[tbd] 


[tbd] 


TCH/F9.6 


18+3+2/1 


106,8 


TCH/H4.8 


18+3+2/1 


106,8 


TCH/F4.8 


36+6+4/1 


212,9 


TCH/F2.4 


7+1/1 


37,5 


TCH/H2.4 


36+6+4/1 


212,9 



NOTE: As an example, the TCH/F9.6 has an interleaving depth of 19, resulting in a delay of 18 TDMA-frames 
and 1 timeslot. Due to the block diagonal interleaving scheme where 4 user data blocks are channel 
encoded together, it may in the worst-case be necessary to wait for all the 4 subblocks spread over 3 
additional TDMA-frames before channel decoding. The channel encoded block will also span a 
maximum of 2 SACCH frames. 

It may be possible, in practice, to reduce the interleaving delay, Trftx, by processing information before the complete 
data block is received over the air interface. It may also be possible, in practice, to reduce the impact of Tframe by 
transmitting information over the air interface before the complete data block is encoded. However, due to the less 
stringent delay requirements on data transmission than on speech transmission, this is considered to unnecessarily 
constrain the implementation options. 

Table 4/3: Delays for bit/character conversion (11 bits) 



Ruser 


Tchar (x): 


75 bit/s 


146,7 ms 


300 bit/s 


36,7 ms 


1 200 bit/s 


9,2 ms 


2 400 bit/s 


4,6 ms 


4 800 bit/s 


2,3 ms 


9 600 bit/s 


1,2 ms 



Table 4/4: Tdframe and Tdbuff given for various TCH types 



Traffic channel: 


Tdframe (u): 


Tdbuff (V): 


TCH/FS 


- 


- 


TCH/HS 


- 


- 


TCH/F9.6 


ms 


ms 


TCH/F4.8 


ms 


20 ms 


TCH/H4.8 


20 ms 


ms 


TCH/F2.4 


ms 


20 ms 


TCH/H2.4 


20 ms 


ms 



NOTE: 



The various figures allocated to the various network entities given in these delay budgets are for guidance 
to network operators for network planning. It is up to the operator to provide other figures, if required. 



The delay value TL2runit has been included in figure 4/4b as "w" ms. No table with values for "w" has been included in 
the present document since these values will depend on the type of data units the incoming user data bit stream shall be 
converted into (e.g. conversion into characters or HDLC frames). 
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Figure 4/3a: Worst-case downlink delay distribution for data TCH (transparent data) 
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Figure 4/3b: Worst-case uplink delay distribution for data TCH (transparent data) 

NOTE: All figures are in ms. The values of x, y, r, u and v depend on the user bitrate, ranging from 75 - 9600 
bit/s, and the data TCH type. 
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Figure 4/4a: Worst-case downlink delay distribution for data TCH (non-transparent data) 
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Figure 4/4b: Worst-case uplink delay distribution for data TCH (non-transparent data) 

NOTE: All figures are in ms. The values of y, z, u, v and w depend on the data TCH type and the L2R user 

protocol. Trlp, diwf and Trlp, uiwf are the transmission delays seen by the RLP in the IWF in the downlink 
and uplink respectively. It should be noted that the corresponding transmission delays seen by the TA are 
given by a symmetrical assessment, but are not identical. The sum of the two, however, is the same. 
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